\documentclass [letterpaper,12pt,oneside,titlepage]  {report}
\usepackage{url}
\usepackage{graphicx}
\usepackage{enumitem}
\usepackage{appendix}
\usepackage{tabularx}
\usepackage[pdftex]{hyperref}
\hypersetup{
colorlinks,%
%citecolor=black,%
%filecolor=black,%
%linkcolor=black,%
linkcolor=blue,%
%urlcolor=black
} 

%make sure the toc section numbers do not overlap the titles
\makeatletter
  \renewcommand\l@section{\@dottedtocline{2}{0.5em}{5em}}
  \renewcommand\l@subsection{\@dottedtocline{2}{2.5em}{6em}}
\makeatother
\begin{document}

  \begin{titlepage}
    \begin{center}
      \rule{\linewidth}{0.5mm} \\[24pt]
      {\Huge \bf \sc Specification and Design for a New Education Management
      Software System}\\[12pt]
      \rule{\linewidth}{0.5mm} \\
      {\large Martin Luther Medical Training School\\
      Accra Ghana}
      \vfill
      \includegraphics[width=0.9\textwidth]{images/lux_logo.pdf}\\[12pt]
      Project contributors\\
      {\large Ryan~Olson, Ben~Petersen, Jared~Plumb, Tyler~Bradovich, Alicia~Windsor, J.D.~Russell, Ryan~Field, Joshua~Clayton, Blaine~Cazinha}\\[36pt]
      \begin{minipage}{0.45\textwidth}
        \begin{flushleft} \large
          \emph{Editor:}\\
          Joshua Clayton
        \end{flushleft}
      \end{minipage}
      \begin{minipage}{0.45\textwidth}
        \begin{flushright} \large
          \emph{Faculty Sponsor:} \\
            Professor Richard Fry
        \end{flushright}
      \end{minipage}\\[6pt]
        \includegraphics[scale=0.25]{images/weber.png}
      {\small Weber State University, Ogden UT, United States of America}
    \end{center}
  \end{titlepage}

  \pagenumbering{roman}
  \setcounter{page}{1}
  {\huge \bf Overview}\\[12pt]
  Lux Aeturna has been selected to design and build a centralized software system 
  for the Martin Luther Health Training School.
  The central goals of the project are to provide a robust and convenient way
  to manage the school's main business functions, which include accepting new students,
  managing courses, releasing grades, assessing fees, collecting fees, and keeping
  records.
  This document provides a detailed overview of the project. It is intended to be
  used as a reference and a communication medium between the project team and client.\\[12pt]
  {\large{\bf Part I}  Requirements Specification}
  \begin{description}
    \item[Section 1] gives a high level overview of the project.
    It describes the need for the project and the proposed solution.
    It also provides some foundational information that is needed to fully
    understand the rest of the document.
    \item[Section 2] explains product functionality as well as assumptions that
    have been made about users and the environment in which they operate.
    \item[Section 3] describes non-functional requirements such as security, performance, and training requirements.
    \item[Section 4] lists ``use cases'' which describe how users will interact with specific parts of the system.
  \end{description}
  {\large{\bf Part II} System Design}
  \begin{description}
    \item[Section 1, 2, 3, 4, 5] describe how the system will be designed,
    including database, code standards, and authentication.
    These sections are primarily for developers.
    \item[Section 6] lists the web pages that are in development along with
    descriptions of what they do. Some early screen shots are included.
  \end{description}
  {\large{\bf Appendices}}
  \begin{description}
    \item[Appendix A] talks about some ideas for the library which cannot be
    included in the first version of the system due to limited resources
    These sections are primarily for developers.
    \item[Appendix B] lays out the revision history of this document
  \end{description}

  \tableofcontents

  \listoffigures

\clearpage
\pagenumbering{arabic}
\setcounter{page}{1}
  \part{Requirements}
    %Normal numbering for sections and subsections. No Chapters

    \def\thesection {Section \arabic{section}}
    \def\thesubsection {\thesection-\arabic{subsection}}
    \setcounter{section}{0}
    \section{Introduction}
      \subsection{Identification}
        \begin{description}
          \item[Project Team] Lux Aeturna, the team of students working to
          design and implement the new software system consists of 4th year
          students at Weber State University in Ogden, UT, USA. The original
          design team consists of JD~Russell, Joshua~Clayton, Ryan~Field, and Alicia~Windsor.
          The implementation team consists of Ryan~Field, Joshua~Clayton, Ryan~Olson, Ben~Petersen, Jared~Plum, Tyler~Bradovich, and Blaine Cazinha.
          The name \emph{Lux Aeturna} is a misspelling of a
          latin phrase meaning eternal light.
          \item[Project Lead]Ryan~Olson is the lead developer on the project.
          \item[Client]The software described in this document is being
          prepared for the Martin Luther Health Training School in Accra, Ghana.
          \item[Client Contact]Dr.~Owusa Duah is the director of Martin Luther Health 
          Training School (MLHTS) and will be the voice of the client throughout the project.
          \item[Faculty Sponsor] Richard Fry, professor of computer science at
          Weber State University, is the project's sponsor and coordinator.
          Professor Fry made the initial arrangements to make this project
          possible. He will also be heading the group of students that will go to
          Ghana to set up the software and and train the users in March 2011.
        \end{description}
      \subsection{Purpose}
      The purpose of the software system described in this document is to help
      streamline the process of tracking students and all of the information
      relevant to their enrollment in the school. The new system will be
      comprised of two major components: An online application form for
      prospective students and a tracking system for students, teachers, and
      other school staff.\\
      This information has historically been stored in Excel spreadsheets
      making it very hard to manage and compile into meaningful reports.\\
      This document describes in detail the functionality of said software and
      its development.
      \subsection{Scope}
      The goals of the project for which Lux Aeturna will be responsible for delivering include
        \begin{enumerate}
          \item Create an online application for enrollment, which
          prospective students may fill out and print, and which may then be
          searched, printed, and responded to by the school staff.
          \item Create a school management system that facilitates management and tracking of:
             \begin{itemize}
                \item Programs of study
                \item Courses taught
                \item Grading of assignments and classes
                \item Fees and payments
                \item Enrollment applications via the internet
                \item Students' personal and contact information
              \end{itemize}
          \item Install the two systems and verify that they are operating correctly
          \item Give one week of on site training to the school staff
        \end{enumerate}
        Things for which Lux Aeturna will not be responsible include
        \begin{enumerate}
          \item Supporting the system once it has been successfully installed
          \item Extending the Fee Ledger to be a general business ledger, or
          supporting its use beyond student fees
          \item Checking books in and out of the library or library inventory
        \end{enumerate}
      \subsection{Definitions Acronyms \& Abbreviations}
        \begin{description}
          \item[SRSS]  System and Software Requirements Specification
          \item[ER Diagram] Entity Relationship Diagram. A popular visual
          format for describing the structure of a database
          \item[Sequence Diagram] A diagram that shows how two or more systems interact 
          as a series of events over time
          \item[Use Case] Project Management jargon for a specific way that a
           person will interact with a system
          \item[Use Case Diagram] A very simple diagram depicting a use case
          \item[MLHTS] Martin Luther Health Training School
          \item[Program] A set schedule of courses that culminate in a certification or degree.
          Program is also associated with the set of students enrolled in it. A program for MLHTS is two years long.
          \item[Course] A semester long class on a given subject.
        \end{description}
      \subsection{References}
        Project Website\\
        \url{https://sites.google.com/site/luxaeturnaproject}\\
        The most up to date version of this document (The SSRS) will always be found in the
        Files section of the project website:\\
        \url{https://sites.google.com/site/luxaeturnaproject/file-cabinet}\\
        For updated timelines and tasks, see project management plan at:\\
        \url{http://projects.zoho.com/portal/luxaeturna}
    \section{Overall Description}
      \subsection{Product Functions}
        \subsubsection{The Enrollment Application System}
          \begin{itemize}
            \item The system shall provide an easy to use web based application form
            \item The system shall provide a way to manage, categorize and contact applicants
          \end{itemize}
        \subsubsection{The Course Management System}
          \begin{itemize}
            \item The system shall provide an interface for managing programs of study, courses, and course schedules
            \item The system shall provide an interface for managing students, enrollment, and student registration
            \item The system shall provide an interface for viewing, managing, and accepting payment for school fees
          \end{itemize}
        \subsubsection{Both Systems}
          \begin{itemize}
            \item The system shall include a means to back it up and restore it
            \item The system shall keep track of and allow reporting of relevant statistics
          \end{itemize}
    \subsection{User Characteristics}
      \begin{description}
        \item[Prospective Student] is a member of the general population in
        Ghana, or one of the surrounding countries. He or she is able to read and write
        English and access the Internet.
        \item[Student] is enrolled in a program at the school.
        \item[Teacher] is a school staff member who teaches at least one class. 
        \item[Librarian] is a school staff member responsible for checking books
        out for student use and keeping track of students that have library books.
        \item[Registrar] is a school staff member who is responsible to get
        students enrolled into the school and registered for classes. The registrar also acts as a
        cashier, recording tuition and fee payments.
        \item[Principal] is the head of a school, reporting directly to the
        director. The principal manages the curriculum, and approves certain changes, such
        as adjustments to student fees or payments.
        \item[System Administrator] is a school staff member who has access to all
        parts of the system, and is expected to support and maintain the system
        and its users after installation. This user needs to have intermediate
        to advanced computer skills.\\
        \emph{Note: The Director and DB Administrator from the organizational
        chart in figure ~\ref{fig:orgchart} are equivalent to System Administrator for the purposes of system access}
      \end{description}
      \begin{figure}[t]
        \setlength\fboxsep{1pt}
        \setlength\fboxrule{0.5pt}
        \fbox{\includegraphics[width=1.0\textwidth]{images/mlh_org_chart.pdf}}
        \caption[Organizational Chart]{All the users of the System are
        represented in this organizational chart, except prospective students,
        which do not yet belong to the school}
        \label{fig:orgchart}
      \end{figure}
    \subsection{Assumptions and Dependencies}
      \begin{itemize}
        \item The school has a server with the ability to host web pages
        \item The database that hosts the school's web page is running and
        functioning properly
        \item There are enough computers with Internet access to allow the
        teachers and staff to use the system
        \item Prospective students are able to access the school's web page via
        the Internet
        \item Teachers and staff are able to access the school's web page via
        the Internet
        \item Students have Internet access outside of campus
      \end{itemize}
  \section{System Level Non-Functional Requirements}
    \subsection{Client Machine Specifications}
The proposed system will be a web based application that will be fully tested and working in the following browsers:
      \begin{itemize}
        \item Internet Explorer 7.0 or later
        \item Firefox 3.0 or later
        \item Google Chrome 7.0 or later
      \end{itemize}
        JavaScript will be used for form validation, so it must be enabled in the target browser.
    \subsection{Server Specifications}
    The system will be built on a server that will be configured with the following open source software:
      \begin{itemize}
        \item Fedora Core Linux Version 14
        \item Apache HTTP Server Version 2.2
        \item PHP Version 5.3
        \item MySQL Community Server Version 5.1
        \item PHPMyAdmin Version 3.3
      \end{itemize}
    \subsection{Site Dependencies}
    The system shall be hosted on a server that will be installed in the school.
    Both the server and client machines will need to be network connected in
    order for clients to access data on the server. The network will preferably
    be a wired Ethernet network, but a wireless network may suffice for
    some clients depending on the site restrictions.
    \subsection{Safety Security and Privacy Requirements}
The server shall be maintained in an environment protected from dust, moisture, and where the ambient temperature is within the recommended range for the specific hardware used.
The system shall define user roles according to what data and parts of the system they are permitted to access and/or alter.
The system shall expose data only to users who are authorized to view it.
The system shall include a secure authentication mechanism.
As a general principle users shall have access to information pertaining to them, and shall have the ability to view and/or alter only information needed to perform their duties.
A principal's approval will be required to modify fees, payments and grades once they have been entered by staff members.
    \subsection{Documentation and Maintainability}
Code contributed to the system shall be liberally commented, such that it may be maintained by developers not initially involved in the project. User documentation shall be written for each user role sufficient to guide a user in exercising the functions of his or her roles. The Lux Aeturna project team will be responsible for maintaining and supporting the software until April 18, 2011. After this date Richard Fry will be responsible for coordinating the maintenance and support of the system.
    \subsection{Packaging and Related Requirements}
The initial version of the software will be installed on the server during the time the team is on site in Ghana. Any additional revisions will be sent via email with complete instructions on how to install and implement the software. All documentation will be delivered via the team website (see references in Section 1). The software will be made available on CD upon request of client.
    \subsection{Training Related Requirements}
Training will primarily take place as the team is on site in Ghana in March, 2011. Formal training will be given over the course of one week in which the available team members will work with each staff member to familiarize them with the system and answer any questions they may have. Basic written manuals will also be made available to each staff member at the time of training.
    \subsection{Logistics Related Requirements}
    The network infrastructure in the school will need to be upgraded in order to
    allow access from all client machines to the server. The project team will
    determine the best way to accomplish this task. When the team is on site
    in March 2011 they will install all necessary networking equipment.
    \subsection{Precedence and Priority of Requirements}
User authentication and security is of high criticality. The system must be secure as it will include confidential personal information including demographics, student grades, and financial information. Users must be only able to see the information that is necessary for them to perform their function in the system. All other requirements are of equal precedence.
  \section{Use Cases}
    \subsection{Student Application System}
      \begin{figure}[p!]
        \setlength\fboxsep{1pt}
        \setlength\fboxrule{0.5pt}
        \fbox{ \includegraphics[width=1.0\textwidth]{images/application_use_case_diagram.pdf}}
        \caption[Application Use Case Diagram]{The {\bf Application Use Case Diagram} gives a very high level view of how all the distinct types of users interact with the application}
      \end{figure}

    \subsubsection{Casual Use Case Descriptions}
      \begin{description}
        \item[Submit Application] Prospective students will be able to visit
        school's website and apply for enrollment. Students will be given a
        simple web form to fill out the necessary information on the application.
        \item[Review Application] Prospective students that have already
        submitted an application will be able to review their previously submitted
        application, and check the current status of their application. School staff
        will be able to review all submitted applications.
        \item[Print Application] Students and school staff will be able to print properly formatted copy of their application.
        \item[Track/Update Application Status] School staff will be able to
        update application status after reviewing submitted application.
        \item[Generate Reports] School staff will be able to generate reports based on aggregate data of all applications in various states of acceptance.
\end{description}

\subsubsection{Detailed Use Case Scenario:\\
Prospective Student Submits Application Form}

{\bf Assumptions}
\begin{itemize}
    \item Prospective Student knows or is able to search for the URL of the Form
    \item User has a computer with a modern browser connected to the Internet
\end{itemize}
{\bf Preconditions}
\begin{itemize}
    \item Server on which Application System is running and connected to the Internet
    \item Web server is running
\end{itemize}
{\bf Scenario Steps}
\begin{enumerate}
    \item User browses to URL for the form
    \item User indicates he/she would like to apply
    \item System prompts user for documentation that may be needed to fill out the form, with the option to abort and start again when he or she has the documents.
    \item User enters his or her information into the form.
    \item System presents the information back to the user, asking for confirmation of its correctness
    \item User affirms the information is correct
    \item System presents the User with a confirmation code, which may be used to identify the application later. System tells the User to print or write down the code. User is given a time frame they should wait before contacting the school, and told to expect an email after that time.
    \item Staff member logs into the system and selects new application forms
    \item System alerts Staff member that a new application is awaiting review. Additional alerts may be made if some Forms have been sitting longer than the expected time.
    \item Staff member selects new application forms
    \item Staff member views the application, and does one of the following:
    \begin{enumerate}
        \item Marks it for Approval- If the user provided an email address an email is sent. Form is moved from new queue to pending approval
        \item Marks it for Denial - If the user provided an email address an email is sent. Form is moved to the Denied queue, where it will stay for at least 90 days, before being purged.
        \item Marks it as needing additional information from the prospective student- If the student provided an email, the staff member will be prompted to write details of what information was missing or unclear, which will be emailed. User may log back in with the confirmation code they received, and update the form. Staff member may contact the user be some other means, and may update the form with the information received
        \item Marks it as needing additional review -This option is for cases where the staff member is not sure whether the user is a good fit, and wants to sleep on it, or consult another staff member before deciding
    \end{enumerate}
    \item User may log back in and see the current status of their form.
    \item If the form is pending approval, user is prompted to pay the application fee, and given instructions on what to do next.
    \item Student pays fee in person
    \item Staff member records the fee, which marks the form as approved
    \item System generates a student record from the data in the form
\end{enumerate}
\begin{figure}[p!]
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/application_sequence_diagram.pdf}}
\caption[Application Sequence Diagram]{Sequence Diagram for the Application shows the flow of events from the prospective student browsing to the page through acceptance as a new student}
\end{figure}

  \subsection{Student Tracking System}
 The System Administration will be responsible for managing the user accounts.
 This will include giving each student, teacher, and staff member a username and
 password to access the system. The School staff will interact with this system the most.
 They will be over what happens with classes, grades, fees, and student information.
 Teachers will have control over who is in their classes and their grades.
 And students will be able to view their grades, bills, and update their information with the system.

    \subsubsection{Casual Use Case Descriptions}
The following explanations are for individual components of the records system.
      \begin{description}
        \item[Manage Course Schedule] The principal will have the ability to create and manage course and
        program descriptions, and manage the schedule of courses within a program.
        The principal will have the ability add or remove a class and session to the system.
        \item[Manage Course Enrollment] A teacher or registrar will have the
        ability to add or remove a student from a course.
        A teacher will only be able to do this for a class for which they are the instructor.
        \item[Set Fees] A principal will be able to set the fees for a course, semester, or program,
        which will be automatically assessed to all students enrolled.
        \item[Manage Fees and Payments] A registrar will have the ability to generate a bill for a student's account.
        A registrar will be able to record a payment and generate a receipt.
        In the event an adjustment is needed to a fee or payment, a principal is required to approve the adjusting transaction.
        \item[Post Library Fees] A librarian will have the ability to post fees for late books
        \item[View Fees]A student will have the ability to view his or her
        outstanding balance and history of fees and payments.
        \item[Submit Grades] A registrar or teacher will be able to submit the student grades.
        A teacher may only do this for their own classes. A registrar can do this for any classes.
        A registrar will also generate the report card containing grades for all of a student's classes.
        \item[View Grades] A student will be able to view his or her own grades.
        \item[Manage Users] A system administrator will be able to manage user and student accounts and set their level of access.
        \item[Manage Personal Information] A user will be able to manage his or
        her own password, public information and contact information
        \item[Manage Alerts] A user will be able to manage the alerts that the system sends to him or her 
      \end{description}  

\begin{figure}[p!]
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/tracking_use_case_diagram.jpg}}
\caption[Student tracking System Use Case Diagram]{The {\bf Student tracking System Case Diagram} gives a very high level view of how all the distinct types of users interact with the main system}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/course_registration_receipt.pdf}}
\caption[Sample Receipt]{A sample receipt for payment of fees}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/mlh_notification_concept.pdf}}
\caption[MLH Notification Concept]{This concept of what a notification screen might look like was produced by
the client to help illustrate the type of information a notification should convey} 
\end{figure}

\begin{figure}[p!]
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/mlh_principal_main_menu_concept.pdf}}
\caption[MLH Principal's Menu Concept]{The client's concept of the menu that
might be presented to a principal}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/mlh_principal_course_menu_concept.pdf}}
\caption[MLH Course Menu Concept]{The client's concept of the menu that
might be used to manage courses}
\end{figure}

\begin{figure}[p!]
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/mlh_registrar_main_menu_concept.pdf}}
\caption[MLH Registrar Main Menu Concept]{The client's concept of the menu that
might be presented to a registrar}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/mlh_registration_menu_concept.pdf}}
\caption[MLH Registration Menu Concept] {The client's concept of the registrar's registration sub-menu}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/pre_registration.pdf}}
\caption[MLH Pre-Registration Concept]{The client's Pre-Registration screen concept with requirements noted in red}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/principal_courses_menu.pdf}}
\caption[MLH Program/Course Menu]{The client's concept of the menu used to add or edit
courses of study with requirements noted in red}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/process_payments.pdf}}
\caption[MLH Payment Screen Concept]{The client's concept of a screen to
accept payments with requirements noted in red}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/special_request.pdf}}
\caption[MLH Special Request Screen Concept]{The client requires certain activities to receive approval from 
the principal. This mock-up shows a concept of what such a screen might look like for the staff member}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/special_request_principal.pdf}}
\caption[MLH Special Request Principal  Screen Concept]{The client requires certain activities to receive approval from 
the principal. This mock-up shows a concept of what such a screen might look like for the principal}
\end{figure}

\part{Software Design}
\setcounter{section}{0}
\section{Authentication}
Authentication will be managed through a custom PHP class. Valid users will be
held in a table in the MySQL database (see the ER diagram in figure ~\ref{fig:school_db_schema}.)
 For security reasons, passwords will be encrypted through a salted MD5 hash in the database.
 Each time a user tries to load any page within the system, the system will
first check to see if the current session has been authenticated and if the session is still valid.
A session ID will be stored in a PHP session variable and is used to key into a table in the MySQL database
that in turn contains information about the current session. If the session is not properly authenticated,
the user will be redirected to the login screen and forced to log in before continuing.
Additionally, sessions will be set to time out after 20 minutes.
\section{Communication Between Pages}
Any data that needs to be communicated between web pages will be passed as POST variables (utilizing hidden fields as needed.)
\section{Coding Standards}
The following standards will apply to all code written in order to enable the creation of homogeneous code:
\begin{enumerate}
    \item All variables, functions, and pages will be given descriptive names.
    \item All variables will be written in lower camel case (I.E. currentGrade)
    \item All functions/methods will be written in upper camel case (I.E. CheckGrade)
    \item All pages will be named using all lowercase letters with words separated by hyphens (I.E. add-new-student.php)
    \item All code will be documented with a brief description of the function, author, and date created/modified.
\end{enumerate}

\section{Database}
The system will be based on a MySQL backend accessed through php pages.
The  structure and nature of the system is largely determined byt the underlying database

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/app_db_schema.pdf}}
\caption[Application Database ER Diagram] {Entity-Relationship Diagram for the Database behind the Application System}
\label{fig:app_db_schema}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=1.0\textwidth]{images/school_db_schema.pdf}}
\caption[Student Tracking System Database ER Diagram]{Entity-Relationship Diagram for the
Database that forms the core of the Student Tracking System}
\label{fig:school_db_schema}
\end{figure}

\section{Programming Objects}
This system will be mainly written using event driven, procedural techniques. However, classes for the following objects will be written:
\subsection{Session Object} - Creates, updates, and tracks the current session and user authentication.
\subsubsection{Methods}
\begin{itemize}
    \item CreateSession
\item IsValidSession
\item RefreshSession
\item GetSessionUser
\item SessionCleanup
\end{itemize}
\section{HTML Pages}
The following pages will be designed (along with the accompanying PHP handlers):

\subsection{Application Page}
Prospective Students Fill out the form to be considered for enrollment by the School
\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/application_ui.png}}
\end{center}
\caption[Application User Interface]{The Application User Interface tries to 
look as much like the original paper application as possible}
\end{figure}

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/application_print_ui.png}}
\end{center}
\caption[Print Application Screen]{After filling out an application,
a prospective student may print it for their records}
\end{figure}

\subsection{Login Page}
Allows users to authenticate using their username and password.
\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/login_ui.png}}
\end{center}
\caption{Login Screen}
\end{figure}

\subsection{Manage Users Page}
Allows the database administrator to add, remove, or modify current staff users of the system.
\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=.8\textwidth]{images/user_add_ui.png}}
\end{center}
\caption{Add User Screen}
\end{figure}

\subsection{Manage Students Page}
 Allows the registrar to add new students to the school.

\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/student_add_ui.png}}
\end{center}
\caption{Add Student Screen Concept}
\end{figure}

\subsection{Manage Schedule Page}
Will allow the registrar to assign students to classes.
\subsection{Manage Courses Page}
Allows for the creation and editing of the classes that are taught at the school
\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/principal_course_mgmt_ui.png}}
\end{center}
\caption{Manage Courses Screen}
\end{figure}

\subsection{Manage Course Instances Page}
Allows for the creation of a specific instance of a class with a specific instructor.

\subsection{Manage Students in Courses Page}
Allows for the assignment of students to classes.
\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/student_select_ui.png}}
\end{center}
\caption{Student Selection Screen}
\end{figure}

\subsection{Manage Fee Schedule Page}
Allows the principal to change/assign fees.

\subsection{Manage Student Bills Page}
Allow the registrar to print bills. 

\subsection{Manage Payments Page}
Allows for the registrar to apply payments and print receipts.
\begin{figure}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\begin{center}
\fbox{\includegraphics[width=0.8\textwidth]{images/student_payment_accept_ui.png}}
\caption{Payment Screen}
\end{center}
\end{figure}

\subsection{Manage Grades Page}
Allows teachers to add grades to students in their classes.
\begin{figure}
\begin{center}
\setlength\fboxsep{1pt}
\setlength\fboxrule{0.5pt}
\fbox{\includegraphics[width=0.8\textwidth]{images/student_grades_ui.png}}
\end{center}
\caption{Grade Entry Screen Concept}
\end{figure}

\subsection{Manage Assignments Page}
 Allows teachers to add assignments to their classes.

\subsection{Generate Reports Page}
Will allow the users to view various reports. Defining what reports will be
produced and what will be in the reports will be worked out with the client.

\subsection{Grades Page}
 Allows a student to view their own grades.

\section{Page Styles}
All common elements will be styled by a master CSS (Cascading Style Sheet) document. Items that are unique to a single page will be styled by CSS in the individual page.

\appendix
\appendixpage
\addappheadtotoc

\chapter{Topics for Future Consideration}
\section{The Library}
The library tracks books checked in and out using a paper system of receipts.
Dr.~Duah, The MLHTS Director has expressed a desire for the system to include support for the library.
The ability for the librarian to assess fees for late books will be included,
but the rest of the functions associated with the library are out of scope for the current phase of the project.
This appendix has been added as a place to put related information in anticipation that it will be implemented some time in the future.

\subsubsection{Users}
\begin{description}
\item[\underline{Librarian}]
Responsible for checking out books (and potentially other media)
\item[\underline{Student}] Check out media from the library with the assistance of a librarian
(Question: should other users such as teachers be able to check out materials, or only students?)
\end{description}
\subsubsection{Use Cases}
\begin{description}
\item[\underline{View Available Media}]
{\bf Students} should be able to see a list of materials that are currently available.
Presumably they should also be able to get some information about materials
that the library has, but which are not available
\item[\underline{Reserve Media}]
A {\bf student} may make a reservation for media that is currently unavailable.
When it becomes available the {\bf student} will be notified, and the item will be
held for a certain time before being returned to the available list.
\item[\underline{Check out Media}]
A {\bf librarian} may check a book out to a {\bf student}. The system will know which {\bf student} has the book and for how long.
\item[\underline{Return Media}]
A {\bf librarian} may record when a checked out book is returned by a {\bf student}
\item[\underline{Late Notifications}]
The system will notify a {\bf student} when his or her book is about to come due,
and will notify the {\bf student} and the {\bf librarian} when the book hits levels of
lateness that are determined to be problematic.
\end{description}

\chapter{Revision History}

\begin{table}[bhp]
\begin{tabularx}{\linewidth}{llX}
\hline
\bf Date & \bf Author & \bf Description of Change\\ \hline
10/01/2010 & JDR &  Original Document compiled from work done by all team members\\ \hline
10/14/2010 & JAC & Moved work breakdown from section one to the end with the plan of work.\\ \hline
10/14/2010 & JAC & Updated section 2\\ \hline
10/15/2010 & JAC & Added user interface mock-ups\\ \hline
11/3/2010 & JDR & Updated UI, ERD, and Descriptions based on feedback from client.\\ \hline
11/10/2010 & JAC & Converted the base document to tex, redesigned the title page\\ \hline
11/25/2010 & JAC & Rewrote significant portions based on infopath and powerpoint docs sent to us by the client\\ \hline
11/29/2010 & JAC & Added all figures except database models to the document\\ \hline
11/30/2010 & JAC & Removed references to the data load, which we will not be doing. Added a Weber Logo, and added Database models\\ \hline
12/01/2010 & JAC & Included changes from Alicia and JD, and made corrections in response to peer reviews.\\ \hline
12/02/2010 & JAC & Added Some definitions and clarified some language per Usability test.\\ \hline
01/23/2011 & RDO & Added new team members to the project contributors.\\ \hline
\end{tabularx}
\caption{Revision History}
\end{table}
\end{document}

